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Description 

Field Of The Invention 

This invention relates generally to the allocation of 
resources within a computer network architecture and, 
more particularly to the use of a broker mechanism 
which responds to a client's or end user's request for 
some service and suggests a server to the client capa- 
ble of supplying the requested service. 

Background Of The Invention 

Present day computer network architectures have 
become more and more complex. For example, a net- 
work may comprise multiple devices, such as several 
computer systems, terminals, peripherals, etc., all 
linked together in order to exchange information and 
share resources. 

Other more complex networks may comprise thou- 
sands of devices of varying technical capabilities. In 
many applications, both local area networks (LANs) and 
wide area networks (WANs) are connected to form parts 
of a single network. For example, a network can include 
a local area component, a wide area component and a 
component involving communication between comput- 
ers of different vendors, such as a multi-vendor commu- 
nication network. 

The process for designing computer networks of 
this type involves a complex analysis of the customer 
requirements, the price factor for the varbus products, 
the necessary communication lines, and other technical 
and business considerations. The allocation and 
planned use of the various resources to support the net- 
work needs is now part of the normal capacity planning 
cycle done by a network manager when setting up the 
network for a customer. 

Because of the potential to form complex networks, 
a computer network client has a wide range of resources 
available to supply requested service. This advantage, 
however, also adds to the problem of networks and re- 
source management. It is therefore desirable to obtain 
delivery of these services through network service 
names. A service offers clients capacity to use in ac- 
cessing resources in the network. 

In these computer networks, a server, made up of 
both hardware and software, may be used as an agent 
between a client and one or more resources to deliver 
the requested service to the client. The server's soft- 
ware program provides "actions" for a client using one 
or more resources. These actions, for example, may be 
transmission of packets over a communication line - a 
communication server; computations in a problem - a 
CPU server; information access in a data base - a data 
base server; network addressing information distributed 
throughout a network and associated with a requested 
service - a name server; or other similar and multiple 
combinations of these functions. 



Because networks may include multiple servers 
generally delivering the same action, a client may ac- 
cess any one of these servers with equal delivery of the 
action. One of the disadvantages in the prior art is the 
5 inability to group these servers providing the same ac- 
tion. This grouping of servers can be seen as a "network 
service'. 

To overcome shortcomings of the prior art an ideal 
system for a client to request a service in a complex net- 
work should fulfill two requirements. First, the request 
must include generic accessing of a particular network 
service name to provide a higher level interface abstrac- 
tion than the current practice where each client knows 
of all server possibilities. This has the advantage of sub- 
stantially simplifying the decision process for the client 
in the case where multiple servers can deliver the re- 
quested service. The only requirement is the network 
service name rather than the name of each and every 
server offering the requested service. Second, the re- 
quested service must be guaranteed to exist for the cli- 
ent within the server for the duration of a connection. 

To supply a service to a client, it is known to use a 
broker mechanism coupled to the network for schedul- 
ing a server to a requesting client. The broker receives 
a request for access to a service from a client and trans- 
mits to the client the name of a server which can deliver 
the service to the client. One known type of broker op- 
erates by assigning an entire server to a client irrespec- 
tive of the capacity needed by the client. 

A problem with the above broker method is the in- 
efficient use of network resources. Prior brokers must 
continuously monitor all of the servers coupled to the 
network, increasing the brokers'overhead and the net- 
work traffic. Because the resource capacities of the 
servers and the necessary performance level to be al- 
located to the client are dynamic factors, a broker mech- 
anism which can dynamically allocate servers to clients 
using a predetermined policy is needed. 

European publication A3 0 248 403 teaches a com- 
plex computer system having several work stations and 
a plurality of host computers. Each work station has a 
built-in process to determine a server process required 
to implement a processing request. A communication 
control establishes a communication path between an 
associated server process and an applicable host. 
There is, however, no broker system in this prior art to 
allocate a plurality of servers. 

SUMMARY OF THE INVENTION 

The present invention is a broker method and ap- 
paratus which, on one hand monitors the dynamic status 
of a set of servers and, on the other hand, responds to 
requests from accessing clients concerning which mem- 
ber of that server set is capable of providing the request- 
ed service. 

The invention, in its broad from, resides in a com- 
puter-implemented method for allocating a plurality of 



15 



20 



25 



30 



35 



40 



45 



50 



3 



EP0 384 339B1 



4 



servers in a network, and a device therefor, as recited 
in claims 1 and 10 respectively. 

The service limitation for the requested service are 
preferably established as a matter of policy during the 
network design and modeling process by a system or 
network manager. Based upon the policy, the broker 
thus suggests to the client a server which is best able 
to satisfy the client's service request. The broker ena- 
bles a client to use a service even though the client is 
unaware of the presence or absence of any individual 
servers within the network. 

According to one aspect of the invention, the client 
then requests the service from the recommended serv- 
er, and the server is responsible for granting the request 
only I f the server currently has the required capacity 
available for that service. Since the server makes the 
final determination of whether it has the available ca- 
pacity to provide the requested service, there is no risk 
of overloading a server because the broker has out of 
date status information - for example, as when a server 
becomes busy subsequent to its last status message 
transmitted to the broker. 

As indicated above, the suggestion of a server prefera- 
bly is based on the network policy developed by the net- 
work manager for the particular network. Because of the 
complex nature of the present networks, a modeling 
process is used to develop a local policy for each server 
in the network to deliver a service, based on the individ- 
ual customer requirements for the network. The collec- 
tion of local policies determines the overall network pol- 
icy for a given service. 

In most cases, the network policy is based on the 
servers' capacity to deliver a given service. The capacity 
of the given service, however, can be changed with the 
addition or subtraction of servers to the network. In ei- 
ther case, the changes are made known to the broker 
and are transparent to the clients in the network. 

Upon startup, the broker develops a linked list data 
structure containing sets of server entries for each of- 
fered service corresponding to the local policy obtained 
for each server. According to one aspect of the inven- 
tion, at any given time, the broker monitors a subset of 
those entries as a "preview window". The broker regu- 
larly rotates different servers into and out of the previous 
window. The broker suggests an entry in the preview 
window, upon receiving a client request, provided the 
entry has the available resources for the client. 

An advantage of the preview window is to substan- 
tially decrease the number of servers which must be 
monitored by the broker in a network. Because the bro- 
ker maintains current status information on only a sub- 
set of the servers during a given time interval, the 
number of status messages required to be transmitted 
over the network is reduced. This results in a reduction 
of computational overhead for the broker and commu- 
nications overhead on the network. 

In this embodiment, the broker assigns servers in a 
round robin fashion to ensure that the loss of a single 



server does not have a major impact upon clients that 
request access at similar times. The application of the 
round robin server distribution, however, is regulated by 
use of a "scan weight" parameter for each server. The 
5 scan weight is definecj as the number of client requests 
which can be satisfied by a server before that server is 
removed from the preview window. 

The advantages of the broker can be achieved with 
only a minimal increase in connect time from client to 
server. This is because the broker uses the preview win- 
dow to monitor server status information prior to receiv- 
ing any client requests. The broker also uses the scan 
weight value to reduce the frequency by which the pre- 
view window is changed thus further increasing accu- 
rate server suggestions by the broker. Therefore, the in- 
cremental client connect time, as opposed to a direct 
client-server connection, is only increased by the time 
needed to contact the broker and receive a suggestion. 

In a further embodiment, the broker suggests to a 
client both the top server entry and the next active server 
entry in the preview window. By suggesting two possible 
servers, the broker compensates for the case in which 
a failure of the first server is alleviated without the need 
to recontact the broker, thus decreasing the load on the 
network. 

Another embodiment of the present invention 
makes use of multiple brokers for suggesting servers to 
multiple different clients. The ability to have multiple bro- 
kers running simultaneously provides a highly reliable 
service by alleviating any single point of failure. 

Brief Description Of The Drawings 

Figure 1 is a block diagram illustrating the environ- 
ment of the present invention. 

Figure 2 is a block diagram of a network architecture 
including the present invention. 

Figure 2A is a block diagram conceptually illustrat- 
ing the broker mechanism of the present invention. 

Figure 3 is a flow chart describing the modelling of 
a network policy according to the present invention. 

Figure 4 is a conceptual block diagram of the broker 
mechanism in Figure 2. 

Figures 5 and 5A are examples showing the oper- 
ation of server datastructures used in the present inven- 
tion. 

Figures 6 and 6A are flow charts describing the op- 
eration of the broker mechanism of the present inven- 
tion. 

Figure 7 is a conceptual block diagram of an em- 
bodiment of the present invention. 

Detailed Description of the Invention 

I. Network Environment 

Referring to Figure 1 , there is shown a model block 
diagram of a system enhanced by the present invention. 
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In a network 5, a plurality of users or clients, generally 
designated 10, each have access to a plurality of serv- 
ers, generally designated 20. Some number of the serv- 
ers 20 can provide access to services A r A n requested 
by one of the clients 10. When the client 10 requests 
access to a service via one of the servers 20, a connec- 
tion is made from the selected client 1 0 through the serv- 
er 20. As can be seen in Figure 1, a plurality of servers 
20 are available to make the requested connection. 
Therefore, it becomes a problem to know which client 
10 should connect to which server 20. Further, the re- 
source capacity of the server 20 must be known in order 
to make an appropriate connection. Because the server 
resources have various and different capabilities, i.e., 
small CPU size, large CPU size, used and unused ca- 
pacities, different serial line speeds, etc., different serv- 
ers 20 are more appropriate for a particular client re- 
quest. Also, it is necessary to know the service level de- 
sired by the client 10. 

Figure 2 is an example of a network architecture in- 
corporating the present invention. The network 5 in- 
cludes a plurality of servers 21 -27 and clients 11-19 cou- 
pled to a communications medium 6, e.g., an Ethernet. 
A broker, conceptually shown as block 30, is also cou- 
pled to the communications medium 6. Further, a dis- 
tributed repository 42 or 44 is illustratively coupled to 
the communication medium 6 for storing network policy. 
These repositories may be replications of each other 
distributed throughout the network. Each server can 
provide access to various services Aj-A,, for a request- 
ing client 11-19. In operation, the broker 30 receives the 
local policies from the repository 42 or 44 for building 
data structures for each service supported by the serv- 
ers, processes client requests for a service, and re- 
sponds in accordance with network policy with one or 
more server suggestions to the client. 

Figure 2A conceptually illustrates the architectural 
diagram of Figure 2. A broker mechanism 30 is used to 
suggest to clients 11 -1 9 an appropriate server 21-26 for 
delivering the requested service (service A1 or A2). Fur- 
ther, individual servers 23, 24 and 25 can provide more 
than one service. While figure 2A only illustrates two 
services, it is apparent that the broker 30 can suggest 
servers to clients requesting any number of different 
services. When a particular client, shown as client 13, 
requests access to service A1, the client 13 places a 
request with the broker 30 on path 54. The broker 30 
suggests an appropriate server from server set 21 -24 to 
the client 13. 

II. Modelling 

A modelling process is used to efficiently determine 
the allocation of resources when designing a network. 
The modelling is accomplished by the network manager 
both prior to implementing the network and upon making 
subsequent changes to the network. In the modelling 
process factors are taken into account such as whether 



data transmissions during the use of a particular net- 
work service are of a bulk or interactive (bursty) nature 
and their effect on resource capacities. Because bulk 
data transfers usually have a high transfer rate i.e., an 
s entire floppy diskette of data is transferred and, on the 
other hand, interactive data transfers generally are of a 
short, bursty nature, it is generally possible in a given 
server to support more interactive data transfers than 
bulk data transfers. 

Figure 3 is a flow chart depicting the modelling proc- 
ess that occurs in the development of the network policy 
to be implemented by the broker mechanism for each 
service. 

The modelling begins by determining the service 
characteristics that are desired by the customer, i.e. the 
various possible actions, and the parameters of the 
server in the network, i.e. the resources of the server. 
Both the server parameters and required service char- 
acteristics are inputs to a modelling process such as is 
described in "Processor - sharing queuing model for 
time-shared systems with bulk arrivals', Klein rock et al, 
Networks v.1 n.1 pp. 1-13 (1971) or "Models for Com- 
puter Networks", Kleinrock, IEEE Int. Conference on 
Communications, Conf. Rec, Boulder, Co, June 9-11, 
Session 21 pp. 9-16 (1969). 

HI. Network Policy 

The model produces a prediction of the measured 
performance characteristics of each server based on 
the performance desired for each service offered by that 
service. This prediction is compared to the desired per- 
formance for each service to check if the server meets 
the performance limitations. If the prediction matches 
the desired performance, then the local policy for that 
particular server has been obtained. However, if the pre- 
diction does not match the desired performance, then 
the local policy parameters of the server and/or the serv- 
ice characteristics are varied before being modeled 
again. This process continues until the server prediction 
matches the desired performance thus developing the 
local policy for the server. 

Next, the modelling process checks whether a local 
policy has been established for each server in the net- 
work. If not, then the above process is repeated. Once 
all local policies have been determined, the local poli- 
cies are collected to form a network policy for the entire 
network. The network policy is stored in the distributed 
repository 42 or 44 as shown in Figure 2. 

When customers set up their network, they there- 
fore establish a network policy to allocate resources for 
each service. Policy decisions must be cognizant of all 
of the available factors made prior to implementing the 
system, i.e., based on the physical constraints of the 
hardware, the communication lines, the price factor for 
the product, the usage toad, i.e., heavy, medium, light, 
fast CPUs, slow CPUs and other appropriate factors. A 
broker implements the network policy when suggesting 
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an appropriate server to maximize the efficiency of the 
complex network. 

IV. Broker 

An advantage of the invention allows the broker 30 
(Figure 2A) to operate when there is: a network policy 
for a given service; a method to easily determine the 
current usage of the server relative to the established 
local policy; and servers which can enforce their local 
policy e.g. by rejecting any connection attempted be- 
yond their local policy limit. These factors are used by 
the broker mechanism 30 to suggest a server 21-26 to 
a requesting client 13 based on the collection of local 
server policies in the broker. 

The data structures of the broker mechanism 30 are 
formed from an application of the distributed repository 
storing the network policy for each service from which 
the broker linked list data structures can be built. Many 
conventional means such as name server computer 
programs are available to facilitate the creation of these 
broker linked list data structures. The distributed repos- 
itory is a non-volatile storage area which holds the col- 
lection of local policies and the attributes of how each 
supporting server supports a service. 

The repository is distributed throughout the net- 
work. As part of the broker startup procedures, the bro- 
ker 30 extracts from the repository attribute information 
about each of the services it implements, i.e., service 
A-, -Aj, as shown in Figure 1 . The repository is necessary 
to store the network policy in the event of a broker failure 
as the broker functions to compare current server ca- 
pacity to network policy 

Figure 4 is a conceptual diagram showing an exam- 
ple of the data structures produced by the code in the 
broker mechanism 30. The data structure shown inside 
the broker 30 are linked lists of entries created by the 
broker code. 

The broker obtains the entries to create the data 
structures from the distributed repository 42. A service 
list 71 is generated for those services found in the re- 
pository 42. Further, a server list 74 is created for each 
service in the service list 71 to hold the local policy in- 
formation for the particular servers 21-26 that support 
the service. Lastly, the broker creates a "server status 
block" which contains a number of server connection en- 
tries 922, 923, 924 and 926, there are being one con- 
nection entry in the server status block for each server 
22, 23, 24 and 26 which currently is in the "preview win- 
dow" of at least one service. (Preview status will be de- 
fined below.) Each connection entry stores the current 
status information for its corresponding server. The pol- 
icy information contained in the server list and service 
lists remains static, while the server status block infor- 
mation is of a dynamic or volatile nature. 

A server connection section 75 of the broker 30 es- 
tablishes communication paths 31-34 with the servers 
referred to in the preceding paragraph. The communi- 
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cation paths 31 -34 allow the broker to poll each coupled 
server (22, 23, 24, 26) to receive its status. The status 
of the servers 22, 23, 24 and 26 is stored in connection 
entries 922, 923, 924 and 926, respectively, within the 

5 server status block. In response to subsequent client re- 
quests for service, the broker examines these connec- 
tion entries to determine each coupled server's capacity 
or availability to deliver a requested service, as will be 
described below with reference to Figures 5 and 5 A. The 

w server connection code 75 therefore supports a list of 
connection entries 922-926 that map (80-84) to a select 
number of server entries in the server lists 74 for each 
of the services in service list 71 . As shown in Figures 4, 
a server 24 can overlap between service offerings. The 

15 server connection code 75 may therefore have several 
server lists 74 with entries pointing to a single server 
connection. This pooling of server connections is impor- 
tant for providing multiple service offerings from one bro- 
ker location. 

20 

1. Preview Window 

During the broker's startup, data structures are de- 
veloped in the broker. The data structures include a 

25 service list 71 and server lists 74 having sets of server 
entries (121-125) and (223-226) corresponding to the 
servers (21-25) and (23-26) for each service (A n & A2) 
in the service list 71 . The data structure information is 
provided from the repository 42. The broker 30 then 

30 monitors, via couplings 80-84, subsets (22, 23 & 24) and 
(24 & 26) of the servers from the above sets to form a 
preview window for each service. The size of the pre- 
view window is predetermined according to the network 
policy and stored as an attribute of the network policy in 

35 the repository 42. The preview windows 72 ensure that 
a sufficient number of servers, i.e., based upon the net- 
work policy for each service, are coupled and providing 
status to the broker 30 for each service before a client 
request is made. The size of the preview window gen- 

40 erally reflects the number of servers necessary to satisfy 
the average rate of client requests received by the bro- 
ker. By using preview windows, the connection time 
from client to servers is reduced by accumulating status 
and policy information in the broker in advance of the 

45 client request. 

Without using the preview windows 72, the precon- 
nection time for a client to receive data from a service 
would be the accumulation of: (client connect time to 
broker) + (broker connect time to server location) + 

so (server startup time) + (accumulation of connect times 
needed to find a server location having unassigned ca- 
pacity). By monitoring the resources of the servers con- 
tained in the preview windows via communication paths 
31-34 associated with each service, the broker 30 can 

55 suggest the top entry in the preview window to a client 
requesting that particular service. The suggestion is 
made provided the entry has the available resources. If 
an entry does not have the available resources it is re- 
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moved from the preview window. Servers are thus reg- 
ularly rotated in and out of the preview window. 

Figures 5 and 5A illustrate by example the data 
structures within each server (shown here as servers 1 
and 2) to indicate server capacity and status to deliver 
a requested service. The status information is provided 
to the broker 30 for comparing the capacity to the local 
policy for each server as shown by communication 
paths 31-34 in Figured 

In Figure 5, server 1 is shown supporting two serv- 
ices 101 and 102 having service names A 1 and A^, re- 
spectively. Similarly, server 2 supports services 103 and 
104 having service names Aj and A2. Associated with 
each service 101-104 is a client capacity number 
111-114 indicating the number of clients that can be 
processed by each server for the particular service. The 
client capacity number reflects the server's local policy 
for each service. As shown in Figure 5, the client capac- 
ity number can be a scalar value which is reduced as 
the server increases its load. The current value of the 
capacity number 111-114 is therefore checked by the 
broker whenever the broker tries to use the server 

A second implementation of the database of server 
1 is shown in Figure 5A wherein client slots 105-1 08 are 
assigned to each service A 1 and A 2 (101 and 102). For 
example, assuming each server has four client slots, 
two client slots (105, 106 and 107, 108) can be allotted 
for each service 101 and 102, respectively in server 1. 
This is equivalent to a client capacity number of two for 
each service 101 or 102. Client slots allow the broker to 
determine the availability of servers by checking a flag 
indicating whether particular client slots are used. 

However, a more powerful use of client slots is 
achieved in server 2 as shown in Figure 5A by allowing 
certain client slots to provide multiple services. Again, 
only four client slots are allocated for server 2. The first 
client slot 115 is dedicated for use with service A-, (103) 
and the second client slot 11 8 is provided for service A2 
(104). In this case, however, the third and fourth client 
slots are made available to each service 116, 117, 119, 
121. Therefore, if three requests are received for service 
Ag and only one request for service A 1 , then by making 
the client slots available for use with each service, ail of 
the requests can be satisfied. Again, this is implemented 
by the server connection section 75 (Figure 4) checking 
flags to determine the availability of each client slot. 
These flags indicate the status for the servers against 
which the local policies are checked in connection en- 
tries 922-926. 

Through the use of the preview window and the 
overlapping of servers to provide different services, the 
broker mechanism 30 thus reduces the number of active 
network connections (31 -34) necessary to poll the serv- 
ers to obtain their status. Otherwise, active connections 
would be required from all of the servers in the network. 
Therefore, only a reasonably managed subset of serv- 
ers is maintained by the broker 30 as active connections 
to reduce message traffic on the network and to simplify 



the computational overhead in the broker. 
B. Scan Weights 

$ Referring again to Figure 4, because the capacity 
of each server to deliver a given service may not be 
equal depending upon the network policy, an additional 
parameter termed scan weight 73 is added. The scan 
weight 73 is the number of client requests which can be 

10 satisfied from a server before the particular server is re- 
moved from the preview window 72. Each server is as- 
signed a particular scan weight value for each service 
by the network manager. The scan weight 73 allows the 
network manager to apply the network policy to more 

is efficiently assign clients 10 to servers in a round-robin 
manner. The values chosen for the scan weight are de- 
veloped as part of the capacity planning modelled in Fig- 
ure 3. 

An example of scan weight operation is given in the 

20 server list 74 for service A-, as shown in Figure 4. Five 
servers 21, 22, 23, 24, and 25 having server entries 
121-125, respectively, are determined to have the fol- 
lowing capacities to access a service for a client: server 
21 ,2 clients(1 0); server 22,6 clients(10); server 23,2 cli- 

25 ents(10); server 24,4 clients( 10); andserver25,2 clients 
(10). Without scan weight, the broker mechanism 30, 
using a purely round robin method of assigning servers, 
would reduce the list of five available servers 21-25 to 
just two available servers 22 and 24 after only 10 client 

30 requests have been suggested. This occurs because 
the servers having the least capacity, i.e. 21 , 23 and 25, 
are suggested as often as the other servers, thus quickly 
using their capacity. After the first ten requests, only 
servers 22 and 24 have any capacity remaining. Further, 

55 only one server 22 would be available after the next four 
client requests. This rapid reduction in the available 
servers can produce single failure points which may dis- 
rupt a network. 

A scan weight parameter 73 is therefore determined 

40 based on an equal distribution of the server capacities 
to handle client requests. The scan weight 73 controls 
the number of clients assigned to a particular server 
when it is at the top of the preview window. In our ex- 
ample, an appropriate allocation of clients per scan 

& weight may be assigned as follows: 21,1 client(10), 22,3 
clients(10); 23,1 client(10); 24,2 clients(10); and 25,1 
(1 0) client. By using these scan weight values, the serv- 
ers having the greatest capacity, i.e. 22 and 24, will be 
assigned to multiple clients before being removed from 

so the preview window. Thus, the client requests are evenly 
distributed across all available servers 21 -25 based on 
their capacity. In this example, four servers would still 
be available after the first ten client requests have been 
satisfied. 

55 
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C. CLIENT CONNECTION and MANAGEMENT OF 
BROKER 

The client connection section 70 of the broker 30 is 
the interface for providing server suggestions to the cli- s 
ents. A clients request for a service is received on path 
54. Client connection section 70 checks to insure that 
the service is located in the service list 71 of supported 
services in the broker 30. Further, client connection sec- 
tion 70 performs the necessary steps to suggest a serv- 10 
er to the accessing client. 

The management section 76 of the broker 30 pro- 
vides control and status information relative to the op- 
eration of the broker 30. For example, the management 
section 76 can enable and disable service names, ex- is 
amines the size of the preview window 72, displays in- s 
formation on the current entries in the preview window, 
or other management functions. 

V. BROKER OPERATION 20 

The operation of Figure 4 is described by the flow 
charts of Figures 6 and 6A. Figure 6 describes the in- 
clusion of the local policies into the operating broker 
mechanism 30. Figure 6A describesthe operation of the 25 
broker upon receiving a client request for a server. 

In operation upon broker 30 start-up, the services i. 
e., service A v A2 or A 3 , are obtained from the network 
list in the distributed repository 42 functioning as a di- 
rectory for all of the services. Once the service is found, 30 
the broker 30 begins to build a service list data structure 
71 which includes the attributes for each of the services. 
Next, the server information for the particular service is 
obtained from the repository 42. If no servers are found, 
then a new service is obtained from the repository 42 35 
and the process is repeated. However, if a server is 
found, then a server list data structure 74 is built for the 
particular service. The server list data structure 74 con- 
tains the local policy for each server supporting the serv- 
ice and the scan weight 73 for each server in the server *o 
list 74. Once ail of the services stored in the repository 
are found, then the server connection section 75 begins 
to build the status connections used for the preview win- 
dows 72 for each service. 

Referring to Figures 4 and 6A, the operation of the 45 
broker upon receiving a client request for a service is 
described. The broker 30 receives a message from the 
client 1 3 via path 54 containing the name of the service 
requested, i.e., service A-,, Ag or A 3 . The client connec- 
tion section 70 receives the request and checks whether so 
the service list 71 exists in the broker. If the service list 
71 exists, the broker 30 checks whether the particular 
service requested (in this example service A2) is con- 
tained in the service list 71 . The broker 30 then obtains 
the top entry 226 in the preview window 72 for service 55 
A2. Next, the broker checks whether the connection en- 
try 926 is active, i.e., is there a connection from broker 
to server as on path 34. If it is not active, then the entry 



226 is removed from the preview window 72. However, 
if the entry 226 is active, then the local policy information 
for the associated server 26 is obtained from entry 226 
in the server list 74. 

The local policy limit is then checked in connection 
entry 926 against the status information received for the 
server 26 on path 34. This is accomplished as described 
above in figures 5 and 5A by checking either the client 
capacity number or the availability of client slots, de- 
pending upon the type of status indication that is used. 

The availability of server 26 to support service A^ is 
checked to make sure that its policy limit is not exceed- 
ed. If the server 26 has the necessary capacity as de- 
termined by either the client slots or the client capacity 
number, i.e. the current value is less than the client ca- 
pacity number or there are available client slots as indi- 
cated by the flags, then, a message is sent to the client 
1 3 suggesting server 26 to be used to deliver service 
A2. The scan weight value 73 for server entry 226 is de- 
creased and is checked to determine if the entry 226 
should be removed from the preview window 72. The 
broker continues by refilling the preview window if nec- 
essary. 

If, however, server 26 does not have the available 
capacity, then the next entry 224 in the preview window 
72 is checked. This process continues until either an en- 
try is found or no server is determined to be available. 
It is thus apparent that broker 30 need only check the 
status of a server when a request for a particular service 
is received and that particular server is in the preview 
window. For each entry in the preview window not hav- 
ing the necessary capacity or having been previously 
assigned, the entry is rotated out of the preview window 
and another entry refills the preview window It may oc- 
cur, however, that no servers are available to refill the 
preview window, in which case the size of the preview 
window would be reduced. 

Under normal operations, the broker mechanism ef- 
ficiently operates to receive client requests and suggest 
servers. However, if at any time during a request, the 
service list, name of the service or preview window do 
not exist, then the broker 30 will send an error message 
to the client 12. 

An alternate embodiment of the present invention 
has the broker 30 suggest to the client 12, not only the 
top server entry 226 but also the next active server entry 
225 in the preview window 72. 

In operation, upon receiving a client request, the 
broker again would check the entry in the preview win- 
dow. Once the broker finds an entry having the available 
capacity, it suggests that entry along with the next entry 
in the preview window. In this embodiment, only the 
scan weight of the first entry is decreased. The client 
then will attempt to access the service through the first 
entry. If however, the first entry fails for any reason, then 
the client attempts to use the second server entry with- 
out having to reconnect to the broker. 

When using this embodiment, the broker does not 
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need to continuously check the status of the two entries. 
The status will be updated the next time the broker 
checks on those particular server entries. 

The use of two entry suggestions is useful in the 
event of a failure by the first server to deliver the request- s 
ed service. Failure of a server can occur due to other 
clients accessing the server directly thus using its ca- 
pacity, failure of the hardware, line damage, etc. Thus, 
suggesting two servers provides for the situation in 
which the first server failed during the client's connection 
time to the server using the broker. The inclusion of a 
second server suggestion provides the client with an al- 
ternate server without having to recontact the broker. 
Thus, client connection time can be decreased by using 
two sewer suggestions. 

As shown conceptually in Figure 7, another embod- 
iment of the present invention incorporates multiple bro- 
kers 30 and 31 for suggesting servers to different clients 
11-19. The brokers 30-31 can be replications of each 
other supporting the same services. The brokers oper- 
ate independently of each other to provide a high avail- 
ability factor to the clients. An attendant tradeoff for the 
availability is an increase in overhead on the network as 
status information for the monitored servers in the pre- 
view window must go to each broker 30, 31 . If however, 
the rate of client requests to the brokers 30, 31 is slow, 
then the brokers can adjust the rate at which they poll 
the servers for their status in the preview window. By 
reducing the polling rate, in proportion to the number of 
brokers, the message traffic on the network will remain 
substantially the same as for a single broker while still 
providing high availability and eliminating the broker as 
a single point of failure. 

Using multiple brokers, the scan weight value in- 
creases is a linear function of the number of brokers in 
the network provided the network policy is consistent 
among the brokers. This occurs because each broker 
maintains a separate preview window and yet the en- 
forcement of the local policies is carried out by each in- 
dividual server. Because servers for the same service 
will be contained in each broker's preview window and 
the brokers are independent of each other, the servers 
will be rotated independently of the other brokers pre- 
view window. Thus, because the server has the same 
scan weight in two separate preview windows, the scan 
weight value is effectively doubled. 

The ability to have multiple brokers 30, 31 operating 
simultaneously provides a highly reliable system by al- 
leviating any single point of failure. Further, the clients 
gain an increased opportunity to use a broker to suggest 
a server for delivering the requested service. 

A further embodiment of the present invention uses 
multiple server lists having different priorities. The dif- 
ferent lists each have their own preview windows. The 
use of prioritized server lists allows the client to obtain 
service when the servers in the higher priority service 
list are unavailable. This is done by automatically redi- 
recting the client requests to the lower server list to pro- 
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vide the service, albeit at a less desirable service level, 
without the client needing to make a request for access 
to an additional service name. 



Claims 

1. A computer-implemented method for allocating a 
plurality of servers (21-27) in a network (5), each 
server having an available resource capacity, to a 
plurality of clients (1 1 -1 9) for delivering a plurality of 
services (A r An) to said clients, the method com- 
prising the steps of: 

a) developing a network policy for said plurality 
of servers (21-27) by collecting a local policy 
for each of said servers, wherein the local policy 
for each server is based on an overall capacity 
of each server to deliver each of the plurality of 
services (A r An) to said clients (11-19); 

b) receiving client requests for said services in 
at least one broker (30, 31); 

c) making a server suggestion, from the broker 
(30, 31) to one of said clients (11-19) making a 
request for one of said sen/ices (A^An), the 
server suggestion identifying a suggested one 
of said servers based on the network policy and 
available resource capacities of said servers, 
said suggested one of said servers having the 
available resource capacity to deliver said one 
of said services; 

d) making a request for said one of said serv- 
ices (At -An) from said one of said clients 
(11-19) to said suggested one of said servers 
(21-27) in response to said one of said clients 
receiving the server suggestion of step (c) from 
the broker (30, 31); 

e) operating the suggested one of said servers 
in accordance with its respective local policy to 
reject the request for said one of said services 
(At -An) of step (d) when the request exceeds 
a local policy limit for the respective local policy 
of the suggested one of said servers; and 

f) operating the suggested one of said servers 
(21-29) in accordance with its respective local 
policy to accept the request for said one of said 
services (At -An) of step (d) when the request 
does not exceed the local policy limit for the re- 
spective local policy of the suggested one of 
said servers. 

2. A method according to claim 1 wherein step (c) fur- 
ther includes: 

a) creating a service list (71 ), within said broker 
(30, 31 ), of available services from said network 
policy; 

b) creating a respective server list (74) for each 
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service in the service list, each server list con- 
taining a server entry for each server having the 
overall capacity to deliver a respective service; 
and 

c) monitoring, for each service in the service list s 
(71 ), a subset of said server entire in said serv- 
er list for suggesting said servers represented 
in said subset to said clients. 

A method according to claim 2 wherein said step of 10 
monitoring said subset further includes the steps of: 

a) establishing a data path (31-34), the data 
path providing connectivity between each serv- 
er represented in the subset and the broker, the '5 
data path for transmitting information regarding 
the available resource capacity of each server 
represented in the subset to said broker; and 

b) determining whether a first server of the serv- 
ers represented in the subset has an available 20 
client slot (105-108) to deliver the service re- 
quested by said clients based upon the availa- 
ble resource capacity of said first server. 

A method according to claim 3 wherein said step of 25 
making a suggestion is made when one of said serv- 
ers being monitored has an available client slot 
(105-108) to deliver said service. 

A method according to claim 4 further comprising 30 
the steps of: 

a) disconnecting the data path (31-34) from 
said first server when said data path indicates 

no available client slots (105-108); and 35 

b) subsequently establishing with the broker 
(30, 31) a data path from another of said plu- 
rality of servers in said server list (74) support- 
ing said service having available client slots. 

40 

A method according to claim 5 further comprising 
the steps of: 

a) developing a scan weight value (73) for each 

of said plurality of servers (21-27) supporting 45 
each service based on said network policy; 

b) creating a scan weight entry containing the 
scan weight value for each server entry in said 
server list (74); 

c) decreasing the scan weight value (73) for a so 
selected one of said servers represented in the 
subset after said selected one is suggested to 
said client; and 

d) removing said selected one from the subset 
when said scan weight value is zero. S5 

A method according to claim 1 , wherein said step 
of developing a network policy includes: 



a) determining a set of service characters for 
each of said services; 

b) determining a service capability for one of 
said servers as a function of said sets of service 
characteristics and a set of server parameters 
of said one of said servers; 

c) comparing the service capability with a de- 
sired performance for said one server to deter- 
mine if there is a match; 

d) varying the sets of service characteristics 
and the set of server parameters until said com- 
paring step produces a match; 

e) storing said set of server parameters and 
said set of service characteristics as the local 
. policy for said one server upon determination 
of a match; 

f) repeating steps (a)-(e) for each of said plu- 
rality of servers; and 

g) collecting said local policies to obtain a net- 
work policy. 

8. A method according to claim wherein said computer 
network (5) uses multiple brokers (30, 31). 

9. A method according to claim 8 wherein said multiple 
brokers (30, 31 ) are exact replicas of each other and 
operating independently. 

10. A device for allocating a plurality of servers (21-27), 
each having an available resource capacity, to a 
plurality of clients (1 1 -1 9) for delivering one of a plu- 
rality of services ( A n -An) to said clients, said servers 
and said clients being arranged in a computer net- 
work (5), the device suggesting a suggested one of 
the plurality of servers (21-27) to a requesting one 
of the plurality of clients (1 1 -1 9), the requesting one 
of the plurality of the clients (11-19) making a re- 
quest for one of the plurality of services (A r An) to 
the suggested one of the plurality of servers, the 
suggested one of the plurality of servers operating 
to reject the request for the one of the plurality of 
services when the request exceeds a local policy 
limit for a respective local policy of the suggested 
one of the plurality of servers (21 -27), the suggest- 
ed one of the plurality of servers operating to accept 
the request for said one of the plurality of services 
(A r An) when the request does not exceed the local 
policy limit for the respective local policy of the sug- 
gested one of the plurality of servers, the device 
comprising: 

a) at least one broker (30, 31) including: 

(i) means for receiving client request for said 
service; and 

(ii) means for suggesting by the broker (30, 31 ) 
one of said servers to one of said clients making 
a request based on an available resource ca- 
pacity, said one server being suggested having 
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ers, the service capability with a desired per- 
formance for each server to determine if there 
is a match; 

c) means for varying, for each of said servers 
(21 -27), the sets of service characteristics and 
the set of local policy parameters until said 
comparing step produces a match; and 

d) means for storing, for each of said servers 
(21 -27), said set of local policy parameters and 
said sets of service characteristics as the local 
policy for each server upon determination of a 
match; 

means for suggesting by the broker (30, 31) 
one of said servers to one of said clients based on 
the network policy and the available resource ca- 
pacity of said one of said servers. 
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the available resource capacity to deliver said 
service. 

11. A device according to claim 10, wherein said serv- 
ice means for suggesting further comprises: 

1 ) means for creating a service list (71 ), within 
said broker (30, 31), of available services; 

2) means for creating a server list (74), contain- 
ing server entries of available servers for sup- 
porting each of said services in said server list; 
and 

3) means for monitoring a subset of said server 
entries in said server list (74) for suggesting 
said servers represented in said server list to 
said clients (11-19). 

12. A device according to claim 10 or 11 wherein said 
means for monitoring further comprises: 

a) a data path (31 -34) establishing connectivity 
from each server in a set of servers supporting 
one of said services to said broker (30, 31 ), the 
data path for indicating available client slots 
(105-108) for the server to said broker; and 

b) means for determining whether said first 
server has an available client slot to deliver the 
service requested by the clients. 

13. A device according to claim 1 2 wherein said means 
for suggesting sends a message to said client when 
one of said servers has an available client slot to 
deliver said service. 

14. A device according to claim 13 further comprising: 

a) a scan weight value (73) developed for each 
of said plurality of servers (21-27); 

b) a scan weight entry containing the scan 
weight value stored in said broker (30, 31) for 
each server entry in said server list; 

c) means for decreasing the scan weight value 
(73) for said first server in the preview window 
(72) after said first server is suggested to said 
client; and 

d) means for removing said first server from the 
preview window (72) when said scan weight 
value is zero. 

15. A device according to claim 12 wherein the device 
further comprises: means for developing a network 
policy including, 

a) means for determining a service capability 
for each server (21-27) based on a plurality of 
sets of service characteristics and a set of local 
policy parameters; 

b) means for comparing, for each of said serv- 



1. Verfahren, das in einem Computer implementiert 
ist, zum Zuweisen mehrerer Server (21-27) in ei- 
nem Netz (5), wovon jeder eine Kapazitat fur ver- 
25 fugbare Betriebsmittel besitzt, an mehrere Clients 
(11-1 9), urn mehrere Dienste (A A -A n ) an die Clients 
zu Hefern, wobei das Verfahren die folgenden 
Schritte enthalt: 

a) Entwickeln einer Netzpolitikfur die mehreren 
Server (21-27) durch Sammeln einer Lokalpo- 
litik fur jeden der Server, wobei die Lokalpolitik 
fur jeden Server auf einer Gesamtkapazitat je- 
des Servers zum Liefern jedes der Dienste (A r 
A n ) an die Clients (11-19) basiert; 

b) Empfangen von Client-Anforderungen der 
Dienste in wenigstens einem Makler (30, 31); 

c) Erzeugen eines Server-Vorschlags vom 
Makler (30, 31) an einen der Clients (11-19), 
der eine Anforderung eines der Dienste (A^A,,) 
erzeugt, wobei der Server- Vorsch lag einen vor- 
geschlagenen der Server auf der Grundlage 
der Netzpolitik und der Kapazitaten fur verf ug- 
bare Betriebsmittel der Server identifiziert, wo- 
bei der vorgeschlagene der Server die Kapazi- 
tat fur verfugbare Betriebsmittel zum Liefern 
des einen der Dienste besitzt; 

d) Erzeugen einer Anforderung des einen der 
Dienste (A-,^) von dem einen der Clients 
(11-19) an den vorgeschlagenen der Server 
(21-27) als Antwort auf den einen der Clients, 
der den Serve r-Vorschlag des Schrittes (c) vom 
Makler (30, 31 ) empfangt; 

e) Betreiben des vorgeschlagenen der Server 
in Ubereinstimmung mit seiner jeweiligen Lo- 
kalpolitik, urn die Anforderung des einen der 
Dienste (A r A n ) des Schrittes (d) zuruckzuwei- 
sen, wenn die Anforderung eine Lokalpolitik- 
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Grenze der entsprechenden Lokalpolitik des 
vorgeschlagenen der Server Oberschreitet; und 
f) Betreiben des vorgeschlagenen der Server 
(21-29) in Obereinstimmung mit seiner jeweili- 
gen Lokalpolitik, urn die Anforderung des einen s 
der Dienste (Aj-AJ des Schrffles (d) anzuneh- 
men, wenn die Anforderung die Lokalpolitik- 
Grenze fur die entsprechende Lokalpolitik des 
vorgeschlagenen der Server nicht Oberschrei- 
tet. 10 

Verfahren nach Anspruch 1 , in dem der Schritt (c) 
ferner enthalt: 

a) Erzeugen einer Dienste-Liste (7 1 ) im Makler is 
(30, 31) der von der Netzpolitik zur Verfugung 
gestellten Dienste; 

b) Erzeugen einer entsprechenden Server-Li- 
ste (74) fur jeden Dienst in der Dienste-Liste, 
wobei jede Server-Liste einen Server-Eintrag 20 
jedes Servers enthalt, der die Gesamtkapazitat 
besitzt, um einen entsprechenden Dienst zu lie- 
fem; und 

c) Uberwachen einer Untermenge der Server- 
Eintrage in der Server-Liste fur jeden Dienst in 2s 
der Dienste-Liste (71 ), um den Clients die Ser- 
ver vorzuschlagen, die in der Untermenge dar- 
gestellt sind. 

r ' 

Verfahren nach Anspruch 2, in dem der Schritt des 30 
Uberwachens der Untermenge femer die folgenden 
Schritte enthalt: 

a) Erstellen eines Datenpfades (31-34), wobei 
der Datenpfad eine Verbindung zwischen je- 35 
dem in der Untermenge dargestellten Server 

/ und dem Makler schafft und der Ubertragung 
von Informationen bezuglich der Kapazitat fur 
verfugbare Betriebsmittel jedes in der Unter- 
menge dargestellten Servers an den Makler 40 
dient; und 

b) Bestimmen auf der Grundlage der Kapazitat 
fur verfugbare Betriebsmittel eines ersten Ser- 
vers der in der Untermenge dargestellten Ser- 
ver, ob der erste Server einen verfugbaren Cli- 45 
ent-Schlitz (105-108) zum Liefem des von den 
Clients angeforderten Diensts besitzt. 

Verfahren nach Anspruch 3, in dem der Schritt des 
Erzeugens eines Vorschlags ausgef uhrt wird, wenn so 
einer der Oberwachten Server einen verfugbaren 
Client-Schlitz (105-108) zum Liefem des Diensts 
besitzt. 

Verfahren nach Anspruch 4, ferner mit den Schrit- 55 
ten: 

a) Trennen des Datenpfades (31-34) vom er- 



sten Server, wenn der Datenpfad keine verfug- 
baren Client-Schiitze (105-108) angibt; und 
b) anschlieBendes Herstellen eines Datenpfa- 
des von einem weiteren der mehreren Server 
in der Server-Liste (74), der den Dienst unter- 
stutzt und verfugbare Client-Schiitze besitzt 
zum Makler (30, 31). 

6. Verfahren nach Anspruch 5, ferner mit den Schrit- 
ten: 

a) Entwickeln eines Abf ragegewichtswerts (73) 
fur jeden der mehreren Server (21-27), die je- 
den Dienst unterstOtzen, auf der Grundlage der 
Netzpolitik; 

b) Erzeugen eines Abfragegewichtseintrags, 
der den Abf ragegewichtswert fur jeden Server- 
Eintrag in der Server-Liste (74) enthalt; 

c) Emiedrigen des Abf ragegewichtswerts (73) 
fur einen ausgewahlten der Server, die in der 
Untermenge dargestellt sind, nachdem der 
ausgewahlte Server fur den Client vorgeschla- 
gen worden ist; und 

d) Entfemen des ausgewahlten Servers aus 
der Untermenge, wenn der Abfragegewichts- 
wert null ist. 

7. Verfahren nach Anspruch 1 , in dem der Schritt des 
Entwickelns einer Netzpolitik enthalt: 

a) Bestimmen einer Menge von Diensteigen- 
schaflen fur jeden der Dienste; 

b) Bestimmen eines Dienst-Vermogens fur ei- 
nen der Server in Abhangigkeit von den Men- 
gen von Dienst-Eigenschaften und einer Men- 
ge von Server-Parametern des einen der Ser- 
ver; 

c) Vergleichen des Dienst-Vermogens mit einer 
gewOnschten Leistungsfahigkeit des einen 
Servers, um festzustellen, ob eine Oberein- 
stimmung vorhanden ist; 

d) Verandern der Mengen von Dienst-Eigen- 
schaften und der Menge von Dienst-Parame- 
tern, bis der Vergleichsschritt eine Obereinstim- 
mung ergibt; 

e) Speichem der Menge von Dienst-Parame- 
tern und der Menge von Dienst-Eigenschaften 
als die Lokalpolitik f Or den einen Server, wenn 
eine Obereinstimmung f estgestellt wird; 

f) Wiederholen der Schritte (a)-(e) fOr jeden der 
mehreren Server; und 

g) Sammeln der Lokalpolitiken, um eine Netz- 
politik zu erhaften. 

8. Verfahren nach Anspruch 1 , in dem das Computer- 
netz (5) mehrere Makler (30, 31) verwendet. 

9. Verfahren nach Anspruch 8, in dem die mehreren 



11 



21 



EP 0 384 339 B1 



22 



Makler (30, 31) exakte Kopien voneinander sind 
und unabhangig arbeiten. 

10. Vorrichtung zum Zuweisen mehrerer Server 
i (21 -27), wovon jeder eine Kapazitat fur verfugbare 
'Betriebsmittel besltzt, an mehrere Clients (11-19) 
zum Liefern eines von mehreren Diensten (A r A n ) 
an die Clients, wobei die Server und die Clients in 
einem Computernetz (5) angeordnet sind, wobei 
die Vorrichtung einem anfordemden der mehreren 
Clients (11-19) einen vorgeschlagenen der mehre- 
ren Server (21 -27) vorschlagt, wobei der anfordern- 
de der mehreren Clients (11-19) einen der mehre- 
ren Dienste (A 1 -An) vom vorgeschlagenen der meh- 
reren Server anfordert, wobei der vorgeschtagene 
der mehreren Server in der Weise arbeitet, daB er 
die Anforderung des einen der mehreren Dienste 
zuruckweist, wenn die Anforderung eine Lokalpoli- 
tik-Grenze fur eine entsprechende Lokalpolitik des 
vorgeschlagenen der mehreren Server (21-27) 
uberschreitet, und wobei der vorgeschlagene der 
mehreren Server in der Weise arbeitet, daG der die 
Anforderung des einen der mehreren Dienste (A r 
AJ annimmt, wenn die Anforderung die Lokalpoli- 
tik-Grenze fur die entsprechende Lokalpolitik des 
vorgeschlagenen der mehreren Server nicht uber- 
schreitet, wobei die Vorrichtung enthalt: 

a) wenigstens einen Makler (30, 31), der ent- 
halt: 

(i) eine Einrichtung zum Empfangen einer 
Client-Anforderung des Diensts; und 

(ii) eine Einrichtung, die auf der Grundlage 
einer Kapazitat fur verfugbare Betriebsmit- 
tel durch den Makler (30, 31 ) einen der Ser- 
ver fur einen der Clients, die eine Anforde- 
rung erzeugen, vorschlagt, wobei der eine 
Server, der vorgeschlagen wird, die Kapa- 
zitat fur verfugbare Betriebsmittel besitzt, 
urn den Dienst zu liefern. 

11. Vornchtung nach Anspruch 10, inderdie Dienstein- 
richtung zum Vorschlagen f emer enthalt: 

1) eine Einrichtung zum Erzeugen einer Dien- 
ste-Liste (71) der verfugbaren Dienste im Mak- 
ler (30, 31); 

2) eine Einrichtung zum Erzeugen einer Ser- 
ver-Liste (74), die Server-Eintrage der verfug- 
baren Server enthalt, die jeden der Dienste in 
der Server-Liste unterstOtzen; und 

3) eine Einrichtung zum Uberwachen einer Un- 
termenge der Server-Eintrage in der Server-Li- 
ste (74), urn den Clients (1 1 -1 9) die in der Ser- 
ver-Liste dargestellten Server vorzuschlagen. 

12. Vorrichtung nach Anspruch 10 oder 11, in der die 



Einrichtung zum Oberwachen femer enthalt: 

a) einen Datenpfad (31-34) zum Herstellen ei- 
ner Verbindung von jedem Server in einer Men- 

5 ge von einen der Dienste unterstutzenden Ser- 

vem zum Makler (30, 31 ), wobei der Datenpfad 
dem Makler verfugbare Client-Schlitze 
(105-108) des jeweiligen Servers anzeigt; und 

b) eine Einrichtung, die feststellt, ob der erste 
10 Server einen verfugbaren Client-Schlitz be- 
sitzt, urn den von den Clients angeforderten 
Dienst zu liefern. 

13. Vorrichtung nach Anspruch 12, in der die Einrich- 
15 tung zum Vorschlagen an den Client eine Nachricht 

sendet, wenn einer der Server einen verfugbaren 
Client-Schlitz besitzt, urn den Dienst zu liefern. 

14. Vorrichtung nach Anspruch 13, femer mit: 

20 

a) einem Abfragegewichtswert (73), der fur je- 
den der mehreren Server (21-27) entwickelt 
wird; 

b) einem Abfragegewichtseintrag, der den im 
25 Makler (30, 31) gespeicherten Abfragege- 
wichtswert fur jeden Server-Eintrag in der Ser- 
ver-Liste enthalt; 

c) einer Einrichtung zum Erniedrigen des Ab- 
fragegewichtswerts (73) des ersten Servers in 

30 einem Vorausschaufenster (72), nachdem der 

erste Server dem Client vorgeschlagen worden 
ist; und 

d) einer Einrichtung zum Entfernen des ersten 
Servers aus dem Vorausschaufenster (72), 

35 wenn der Abfragegewichtswert Null ist. 

15. Vorrichtung nach Anspruch 12, wobei die Vorrich- 
tung femer enthalt: 

eine Einrichtung zum Entwickeln einer Netz- 
40 politik, mit 

a) einer Einrichtung zum Bestimmen eines 
Dienst- Vermogens fur jeden Server (21 -27) auf 
der Grundlage mehrerer Mengen von Dienst- 

45 Eigenschaften und einer Menge von Lokalpoli- 

tik-Parametem; 

b) einer Einrichtung zum Vergleichen des 
Dienst-Vermogens mit einer fur jeden Server 
gewunschten Leistungsfahigkeit fur jeden Ser- 

50 ver, urn festzustellen, wenn eine Ubereinstim- 

mung vorhanden ist; 

c) einer Einrichtung zum Verandem der Men- 
gen von Dienst-Eigenschaften und der Menge 
von Lokalpolitik-Parametem fur jeden der Ser- 

55 ver (21 -27), bis der Vergleichsschritt eine Uber- 

einstimmung ergibt; und 

d) einer Einrichtung zum Speichem der Menge 
von Lokalpolitik-Parametem und der Mengen 
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von Diensteigenschaften als die Lokalpolitik je- 
des Servers fur jeden der Server, wenn eine 
Obereinstimmung festgestellt wird; 

eine Einrichtung, die durch den Makler (30, 
31) auf der Grundlage der Netzpolitik und der Ka- 
pazitat fOr verf Ggbare Betriebsmittel eines der Ser- 
ver den einen der Server fur einen der Clients vor- 
schlagt. 



Revendications 

1 . Procydy mis en oeuvre par ordinateur pour affecter 
une multiplied de serveurs (21 ft 27) dans un r6- 
seau (5), chaque serveur ayant une capacity en 
ressources dlsponible, ft une multiplicity de clients 
(11 & 19) pour foumir une multiplicity de services 
(A, ft AJ auxdits clients, le precede comportant les 
ytapes consistant: 



10 



15 



20 



a) ft 6 laborer une politique de r6seau pour iadite 
multiplicity de serveurs (21 ft 27) en recueillant 
une politique locale pour chacun desdits ser- 
veurs, la politique locale pour chaque serveur 25 
6tant bas6e sur une capacity globale de cha- 
que serveur ft fournir chaque service de la mul- 3. 
tiplicity de services (A-, ft AJ auxdits clients (11 

ft 19); 

b) k recevoir des demandes de clients pour les- so 
dits services dans au moins un courtier (30, 31 ); 

c) k faire une proposition de serveur, k partir du 
courtier (30, 31), k I'un desdits clients (11 k 19) 
faisant une demande de Tun desdits services 

(A 1 k A n ), la proposition de serveur identifiant 35 
un serveur proposy parmi lesdits serveurs sur 
la base de la politique de r£seau et des capa- 
city en ressources disponibles desdits ser- 
veurs, ledit serveur proposy parmi lesdits ser- 
veurs ayant la capacity en ressources disponi- 40 
ble nycessaire k \a fourniture de I'un desdits 
services; 

d) k faire la demande de Tun desdits services 
(A, ft A^ de la part de I'un desdits clients (11 ft 
19) audit serveur proposy parmi lesdits ser- 

veurs (21 ft 27) en ryponse ft la reception par 4. 
ledit client parmi lesdits clients de la proposition 
de serveur de I'ytape (c) de la part du courtier 
(30, 31); 

e) ft faire fonctionner le serveur proposy parmi so 
lesdits serveurs conformyment ft sa politique 
locale respective pour rejeter la demande dudit 5. 
service parmi desdits services (A^ ft A n ) de 
I'ytape (d) lorsque la demande depasse une li- 

mite de politique locale pour la politique locale 55 
respective du serveur proposy parmi lesdits 
serveurs; et 

f) ft faire fonctionner le serveur proposy parmi 



lesdits serveurs (21 ft 27) conformyment ft sa 
politique locale respective pour accepter la de- 
mande dudit service parmi lesdits services (A 1 
ft AJ de Pytape (d) lorsque la demande ne dy- 
passe pas la limite de politique locale pour la 
politique locale respective du serveur proposy 
parmi lesdits serveurs. 

Precede selon la revendication 1 , dans lequel I'yta- 
pe (c) consiste, en outre: 

(a) ft creer une liste de services (71), ft I'inty- 
rieur dudit courtier (30, 31 ), des services dispo- 
nibles ft partir de Iadite politique de r6seau; 

b) ft cryer une liste de serveurs respectifs (74) 
pour chaque service de la liste de services, 
chaque liste de serveurs contenant une entrye 
de serveur pour chaque serveur ayant la capa- 
city globale nycessaire ft la fourniture d'un ser- 
vice respectif; et 

c) ft contrdler, pour chaque service de la liste 
de services (71), un sous-ensemble desdites 
entryes de serveur dans Iadite liste de serveurs 
pour proposer lesdits serveurs reprysentys 
dans ledit sous-ensemble auxdits clients. 

Procydy selon la revendication 2, dans lequel Iadite 
ytape de contrdle dudit sous-ensemble comprend, 
en outre, les ytapes consistant: 

a) ft ytablir un chemin de donn6es (31 k 34), le 
chemin de donnyes assurant la connectivity 
entre chaque serveur represents dans le sous- 
ensemble et le courtier, le chemin de donnyes 
transmettant des informations concernant la 
capacity en ressources disponible de chaque 
serveur reprysente dans le sous-ensemble 
audit courtier; et 

b) ft determiner si un premier serveur parmi les 
serveurs reprysentys dans !e sous-ensemble a 
un compartiment client disponible (105 ft 108) 
pour fournir le service demandy par lesdits 
clients sur la base de la capacity en ressources 
disponible dudit premier serveur. 

Procydy selon la revendication 3, dans lequel Iadite 
ytape consistant ft faire une proposition est exycu- 
tye lorsque I'un desdits serveurs faisant i'objet de 
controles a un compartiment client disponible (105 
ft 108) pour fournir ledit service. 

Procydy selon la revendication 4, comportant en 
outre les ytapes consistant: 

a) ft dyconnecter le chemin de donnyes (31 ft 
34) dudit premier serveur lorsque ledit chemin 
de donnyes n'indique pas la presence de com- 
partments client disponibles (105 ft 108); et 
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b) k etablir subs§quemment avec le courtier 
(30, 31) un chemin de donnSes partant d'un 
autre serveur de ladite multiplicity de serveurs 
de ladite liste de serveurs (74) pouvant prendre 
en charge ledit service et ayant des comparti- s 
ments client disponibles. 

Proceed selon la revendication 5, comportant en 
outre les Stapes consistant: 

io 

a) k elaborer une valeur de pond6ration d'ana- 
lyse (73) pour chacun des serveurs de ladite 
multiplicity de serveurs (21 k 27) pouvant pren- 
dre en charge chaque service sur la base de 
ladite politique de r£seau; is 

b) k cr6er une entr6e de pond6ration d'analyse 
contenant la valeur de pondgration d'analyse 
pour chaque entree de serveur de ladite liste 
de serveurs (74); 

c) k require la valeur de pond^ration d'analyse 20 
(73) pour un serveur s6lectionn6 parmi lesdits 
serveurs represented dans le sous-ensemble 
apres que ledit serveur s6lectionn6 a 6t6 pro- 
posy audit client; et 

d) k retirer ledit serveur selectionn6 du sous- 25 
ensemble lorsque ladite valeur de pond6ration 
d'analyse est de z6ro. 

Procede selon la revendication 1 , dans lequel ladite 
etape d'eiaboration d'une politique de r6seau con- so 
siste: 

a) k determiner un ensemble de caracteristi- 
ques de service pour chacun desdits services; 

b) k determiner une capacity en services pour 3S 
I'un desdits serveurs en fonction desdits en- 
sembles de caractyristiques de service et d'un 
ensemble de parametres de serveur dudit ser- 
veur parmi lesdits serveurs; 

c) k comparer la capacity en services k une per- 40 
formance souhaitye pour ledit serveur afin de 
determiner s'il y a correspondance; 

d) k faire varier les ensembles de caractyristi- 
ques de service et Pensemble de parametres 

de serveur jusqu'a. ce que ladite ytape de com- 45 
paraison produise une correspondance; 

e) k emmagasiner ledit ensemble de parame- 
tres de serveur et ledit ensemble de caracteris- 
tiques de service en tant que politique locale 
pour ledit serveur lorsqu'une correspondance so 
est determines; 

f) k rep6ter les etapes (a) k (e) pour chaque 
serveur de ladite multiplicity de serveurs; et 

g) k recueillir lesdites politiques locales pour 
obtenir une politique de reseau. ss 

Procede selon la revendication 1 , dans lequel ledit 
ryseau informatique (5) utilise de multiples courtiers 



(30,31). 

9. Procede selon la revendication 8, dans lequel les- 
dits multiples courtiers (30, 31) constituent des r6- 
pliques exacts les uns des autres et fonctionnent 
indypendamment. 

10. Dispositif pour affecter une multiplicity de serveurs 
(21 k 27), ayant chacun une capacity en ressources 
disponible, k une multiplicity de clients (11 k 19) 
pour foumir un service parmi une multiplicity de ser- 
vices (A 1 k \) auxdits clients, lesdits serveurs et 
lesdits clients etant disposes dans un reseau infor- 
matique (5), le dispositif proposant un serveur pro- 
posy parmi la multiplicity de serveurs (21 k 27) a un 
client demandeur parmi la multiplicity de clients (11 
k 19), le client demandeur parmi la multiplicity de 
clients (1 1 & 1 9) faisant la demande de I'un des ser- 
vices de la multiplicity de services (A, k A n ) k un 
serveur proposy parmi la multiplicity de serveurs, 
le serveur proposy parmi la multiplicity de serveurs 
fonctionnant de maniere k rejeter la demande de 
Tun des services de la multiplicity de services lors- 
que la demande d6passe une limits de politique lo- 
cale pour une politique locale respective du serveur 
propose parmi la multiplicity de serveurs (21 k 27), 
le serveur proposy parmi la multiplicity de serveurs 
fonctionnant de maniere k accepter la demande du- 
dit service parmi la multiplicity de services (A & k AJ 
lorsque la demande ne d6passe pas la limite de po- 
litique locale pour la politique locale respective du 
serveur proposy parmi la multiplicity de serveurs, 
le dispositif comportant: 

a) au moins un courtier (30, 31) comprenant: 

(i) des moyens pour recevoir une demande 
de client pour ledit service; et 

(ii) des moyens pour proposer de la part du 
courtier (30, 31) I'un desdits serveurs k I'un 
desdits clients faisant une demande sur la 
base d'une capacity en ressources dispo- 
nible, ledit serveur proposy ayant la capa- 
city en ressources disponible necessaire a 
la fourniture dudit service. 

11 . Dispositif selon la revendication 10, dans lequel les- 
dits moyens de proposition de serveur component, 
en outre: 

1 ) des moyens pour cr6er une liste de services 
(71), k I'interieur dudit courtier (30, 31), de ser- 
vices disponibles; 

2) des moyens pour creer une liste de serveurs 
(74) contenant des entrees de serveur des ser- 
veurs disponibles pour prendre en charge cha- 
cun desdits services de ladite liste de services; 
et 
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3) des moyens pour contrdier un sous-ensem- 
ble desdites entries de serveur de ladtte liste 
de serveurs (74) pour proposer lesdits serveurs 
repr6sent6s dans ladite liste de serveurs 
auxdits clients (11 a 19). s 

12. Dispositif selon la revendication 10 ou 11, dans le- 
quel lesdits moyens de contrdle comprennent, en 
outre: 

10 

a) un chemin de donnSes (31 a 34) etablissant 
la connectivity entre chaque serveur d'un en- 
semble de serveurs pouvant prendre en charge 
Pun desdits services et ledit courtier (30, 31 ), le 
chemin de donnees indiquant des comparti- is 
ments client disponibles (105 a 108) pour le 
serveur audit courtier; et 

b) des moyens pour determiner si ledit premier 
serveur a un compartiment client disponible 
pour foumir le service demande par les clients. 20 

1 3. Dispositif selon la revendication 1 2, dans lequel les- 
dits moyens de proposition envoient un message 
audit client lorsque Tun desdits serveurs a un com- 
partiment client disponible pour la foumiture dudit & 
service. 



b) des moyens pour comparer, pour chacun 
desdits serveurs, la capacity en services a une 
performance souhaitee pour chaque serveur 
afin de determiner s'il existe une correspondan- 
ce; 

c) des moyens pour faire varier, pour chacun 
desdits serveurs (21 a 27), les ensembles de 
caracteristiques de service et I'ensemble de 
parametres de politique locale jusqu'a ce que 
ladite etape de comparaison produise une cor- 
respondance; et 

d) des moyens pour emmagasiner, pour cha- 
cun desdits serveurs (21 a 27), ledit ensemble 
de paramdtres de politique locale et lesdits en- 
sembles de caracteristiques de service en tant 
que politique locale pour chaque serveur lors 
de la determination d'une correspondance; 

des moyens pour proposer, de la part du cour- 
tier (30, 31), Tun desdits serveurs a Pun desdits 
clients sur la base de la politique de r6seau et de la 
capacite en ressources disponible dudit serveur 
parmi lesdits serveurs. 



14. Dispositif selon la revendication 13, comportant, en 
outre: 

30 

a) une valeur de ponderation d'analyse (73) 
6labor6e pour chacun des serveurs de ladite 
multiplicity de serveurs (21 a 27); 

b) une entr6e de ponderation d'analyse cove- 
nant la valeur de ponderation d'analyse emma- 35 
gasinee dans ledit courtier (30, 31) pour cha- 
que entree de serveur de ladite liste de ser- 
veurs; 

c) des moyens pour reduire la valeur de pon- 
deration d'analyse (73) pour ledit premier ser- 40 
veur dans la fenetre de pre-visualisation (72) 
aprds que ledit premier serveur a 6t6 propose 
audit client; et , 

d) des moyens pour retirer ledit premier serveur 

de la fenetre de pre-visualisation (72) lorsque *s 
ladite valeur de ponderation d'analyse est de 
zero. 



15. Dispositif sebn la revendication 12, dans lequel le 
dispositif comporte, en outre: so 

des moyens pour etaborer une politique de re- 
seau, comprenant: 

a) des moyens pour determiner une capacite 
en services pour chaque serveur (21 a 27) sur ss 
la base d'une multiplicity d'ensembles de ca- 
racteristiques de service et d'un ensemble de 
parametres de politique locale; 
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